Add True-Client-IP custom header to be passed along to BAPI #298
Conversation
NicolasLopes7
force-pushed
the
feat/add-true-client-ip-on-header
branch
from
6b0abf0 to
790d2c9
Compare
|
@NicolasLopes7 Could you please provide more information on what this change is about, and why we need it/what problem it currently solves? Thanks! |
clerk.go
Outdated
| @@ -169,6 +170,7 @@ func (h *CustomRequestHeaders) apply(req *http.Request) { | |||
| return | |||
| } | |||
| req.Header.Add("X-Clerk-Application", h.Application) | |||
| req.Header.Add("True-Client-IP", h.TrueClientIP) | |||
There was a problem hiding this comment.
🔧 This is a semi-standard header name and can potentially cause issues if it's being set on the request directly. Better use the X-Clerk- namespace here as well?
There was a problem hiding this comment.
Done! That makes sense!
NicolasLopes7
force-pushed
the
feat/add-true-client-ip-on-header
branch
from
790d2c9 to
1941c28
Compare
Added on the description 👍 |
| @@ -169,6 +170,7 @@ func (h *CustomRequestHeaders) apply(req *http.Request) { | |||
| return | |||
| } | |||
| req.Header.Add("X-Clerk-Application", h.Application) | |||
| req.Header.Add("X-Clerk-True-Client-IP", h.TrueClientIP) | |||
There was a problem hiding this comment.
🙃 Perhaps the "True" portion of the name is a bit too much?
| req.Header.Add("X-Clerk-True-Client-IP", h.TrueClientIP) | |
| req.Header.Add("X-Clerk-Client-IP", h.ClientIP) |
| @@ -160,7 +160,8 @@ type Params interface { | |||
| // CustomRequestHeaders contains predefined values that can be | |||
| // used as custom headers in Backend API requests. | |||
| type CustomRequestHeaders struct { | |||
| Application string | |||
| Application string | |||
| TrueClientIP string | |||
There was a problem hiding this comment.
❓ How will this field be used?
The CustomHeaders struct is provided upon the Backend initialization and does not dynamically track values for every request.
See
Line 210 in 39bb339
The test that's updated in this PR shows exactly this. The value of the x-clerk-true-client-ip header will always be "127.0.0.1" no matter where the request comes from.
Hope I'm not missing anything, but are we sure this PR solves our problem?
There was a problem hiding this comment.
That makes sense @gkats, great catch! I'll sync with you tomorrow to understand how can I just pass the headers coming along from a request (if possible). Closing this PR!
This PR adds the
True-Client-IPheader on the custom headers map in order to pass it along our APIs. We are introducing request info on the webhook and that will enable us to know who has called other than the user-agent.